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ABSTRACT 


We extend previous dependence-based representations called 


system dependence graphs (SDGs) to represent aspect-oriented 


programs and present an SDG construction algorithm. This 
algorithm first constructs a module dependence graph (MDG) 
for each piece of advice, introduction, and method in aspects 
and classes. It then uses existing techniques to connect the 
MDGs at call sites to form a partial SDG. Finally, it weaves 
the MDG for each piece of advice into the partial SDG for 
those methods whose behavior may be affected by the ad- 
vice. The result is the complete SDG. Our SDGs capture 
the additional structure present in many aspect-oriented fea- 
tures such as join points, advice, introduction, aspects, and 
aspect inheritance, and various types of interactions between 
aspects and classes. They also correctly reflect the semantics 
of aspect-oriented concepts such as advice precedence, intro- 
duction scope, and aspect weaving. SDGs therefore provide 
a solid foundation for the further analysis of aspect-oriented 
programs. 


1. INTRODUCTION 


The program dependence graph (PDG) effectively supports 
powerful program analysis by explicitly capturing depen- 
dence information between different program elements [6]. 
Although originally proposed for compiler optimizations, the 
PDG has also been used as an effective foundation for vari- 
ous software engineering tasks such as program understand- 
ing, debugging, testing, and maintenance [3, 16, 17]. PDGs 
were originally constructed for procedural programs [6, 7], 
and have been recently extended to support various object- 
oriented features such as classes and objects, inheritance, 
polymorphism, and dynamic binding [11, 13, 14, 15]. 


Aspect-oriented programming (AOP) [8, 19] is a new lan- 
guage paradigm proposed for cleanly modularizing the cross- 
cutting structure of concerns such as exception handling, 
synchronization, and resource sharing. Expressing such cross- 
cutting concerns using standard language constructs usually 
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produces tangled, poorly structured code. AOP can control 
such code tangling, improving the structure of the program 
and making it easier to develop and maintain. 


Aspect-oriented languages present unique opportunities and 
problems for program representation schemes. To enable 
the development of effective analysis for aspect-oriented pro- 
grams, the program representation scheme must appropri- 
ately preserve the structure associated with the use of fea- 
tures such as joint points, advice, and introduction. It is 
therefore of interest to develop appropriate program repre- 
sentations for aspect-oriented programs. 


Although researchers have developed many representations 
for procedural and object-oriented programs, little work has 
been carried out on representations that preserve the struc- 
ture of aspect-oriented programs. Due to some specific aspect- 
oriented features presented in recent AOP languages, exist- 
ing representations for procedural and object-oriented pro- 
grams can not be used directly for aspect-oriented programs. 


In this paper we extend previous dependence-based repre- 
sentations called system dependence graphs (SDGs) to rep- 
resent aspect-oriented programs and present an SDG con- 
struction algorithm. This algorithm first constructs a mod- 
ule dependence graph (MDG) for each piece of advice, in- 
troduction, and method in aspects and classes. It then uses 
existing techniques to connect the MDGs at call sites to form 
a partial SDG. Finally, it weaves the MDG for each piece of 
advice into the partial SDG for those methods whose behav- 
ior may be affected by the advice. The result is the complete 
SDG. Our SDGs capture the additional structure present in 
many aspect-oriented features such as join points, advice, 
introduction, aspects, and aspect inheritance, and various 
types of interactions between aspects and classes. They also 
correctly reflect the semantics of aspect-oriented concepts 
such as advice precedence, introduction scope, and aspect 
weaving. SDGs therefore provide a solid foundation for the 
further analysis of aspect-oriented programs. One key point 
for representing aspect weaving is to determine, for each 
pointcut pc, a set of methods in classes that might be af- 
fected by pc. Based on this kind of information, we can 
weave the MDGs for advice into the partial SDG for base 
code in a natural way. 


Our main contribution in this paper is a new representation 
for aspect-oriented programs. This representation can serve 
as an effective foundation for program analysis. Because the 
representation preserves the additional structure present in 


ce0 public class Point { 
sl protected int x, y; 

me2 public Point(int x1, int yl) { 
s3 x x1; 
s4 ye=yi; 


me5 public int getx() { 
s6 return x; 


me7 public int gety() { 
s8 return y; 


me9 public void setX(int x) { 
s10 x = xX; 


mell public void sety(int y) { 
s12 y= _y: 
} 
me13 public void printPosition() { 
s14 System.out.printlin("Point at ("+x+","+y+")"); 


me15 public static void main(String[] args) { 
s16 Point p = new Point(1,1); 
s17 p.setX(2); 
s18 p.setY(2); 


class Shadow { 
public static final int offset = 10; 
public int x, y; 


Shadow(int x, int y) { 
this.x = x; 
this.y = y; 
public void printPosition() { 
System.outprintln("Shadow at 
("4x4", Ney+") m) ; 


(a) 


i ase27 aspect PointShadowProtocol { 


s28 private int shadowCount = 0; 
me29 public static int getShadowCount() { 
s30 return PointShadowProtocol. 
aspectOf () .shadowCount; 


s31 private Shadow Point.shadow; 
me32 public static void associate(Point p, Shadow s){ 
833 p.shadow = s; 


me34 public static Shadow getShadow(Point p) { 
s35 return p.shadow; 


p36 pointcut setting(int x, int y, Point p): 

args(x,y) && call(Point.new(int,int) ); 
p37 pointcut settingX(Point p): 

target(p) && call(void Point.setX(int) ); 
p38 pointcut settingY(Point p): 

target(p) && call(void Point.setY(int)); 


ae39 after(int x, int y, Point p) returning : 
setting(x, y, p) 


s40 Shadow s = new Shadow(x,y); 
s41 associate(p,s); 
s42 shadowCount++; 


ae43 after (Point p): settingX(p) { 


s44 Shadow s = new getShadow(p) ; 
s45 S.x = p.getX() + Shadow.offset; 
s46 p.printPosition() ; 

s47 s.printPosition() ; 


ae48 after (Point p): settingY(p) { 


s49 Shadow s = getShadow(p) ; 

s50 S.y = p.getY() + Shadow.offset; 
s51 p.printPosition(); 

s52 } s.printPosition(); 


(b) 


Figure 1: An AspectJ program which contains (a) base code and (b) aspect code. 


the aspect-oriented program, it is especially appropriate for 
developing software engineering tools. 


The rest of the paper is organized as follows. Section 2 
briefly introduces the system dependence graph for standard 
object-oriented programs and presents the aspect-oriented 
programming language AspectJ. Section 3 presents the SDG 
for aspect-oriented programs and the construction algorithm 
for an SDG. Section 4 discusses some related work; we con- 
clude in Section 5. 


2. BACKGROUND 


We next briefly introduce the AspectJ language and the sys- 
tem dependence graphs for object-oriented programs. 


2.1 Aspect-Oriented Programming with As- 


pectJ 
We present our extended SDG in the context of AspectJ, the 
most widely used aspect-oriented programming language. 
[9]. Our basic techniques, however, deal with the basic con- 
cepts of aspect-oriented programming and therefore apply 
to the general class of AOP languages. 


AspectJ [9] is a seamless aspect-oriented extension to Java; 
AspectJ adds some new concepts and associated constructs 
to Java. These concepts and associated constructs are called 
join points, pointcut, advice, introduction, and aspect. We 
briefly introduce each of these constructs as follows. 


The aspect is the modular unit of crosscutting implemen- 
tation in AspectJ. Each aspect encapsulates functionality 
that crosscuts other classes in a program. Like a class, 


an aspect can be instantiated, can contain state and meth- 
ods, and also may be specialized with subaspects. An as- 
pect is combined with the classes it crosscuts according to 
specifications given within the aspect. Moreover, an aspect 
can use an introduction construct to introduce methods, 
attributes, and interface implementation declarations into 
classes. Introduced members may be made visible to all 
classes and aspects (public introduction) or only within the 
aspect (private introduction), allowing one to avoid name 
conflicts with pre-existing elements. For example, the as- 
pect PointShadowProtocol in Figure 1 privately introduces 
a field shadow to the class Point at s31. 


A central concept in the composition of an aspect with other 
classes is called a join point. A join point is a well-defined 
point in the execution of a program, such as a call to a 
method, an access to an attribute, an object initialization, 
an exception handler, etc. Sets of join points may be rep- 
resented by pointcuts, implying that such sets may crosscut 
the system. Pointcuts can be composed and new pointcut 
designators can be defined according to these combinations. 
AspectJ provides various pointcut designators that may be 
combined through logical operators to build up complete de- 
scriptions of pointcuts of interest. For example, the aspect 
PointShadowProtocol in Figure 1 declares three pointcuts 
named setting, settingX, and settingY at p36, p37, and 
p3s. 


An aspect can specify advice, which is used to define code 
that executes when a pointcut is reached. Advice is a method- 
like mechanism which consists of instructions that execute 
before, after, or around a pointcut. around advice executes 
in place of the indicated pointcut, allowing a method to be 


f1_in: x=x_in 
f1_out: x_out=x 
£2_in: y=y_ in 

£2_out: y_out=y 


a5_out: x=x_out 


a6 out: y=y out 


parameter-in, 
parameter-out, or call are 


—_—» 


summary arc 


Figure 2: SDG for the base code of program in Fig- 
ure 1. 


replaced. For example, the aspect PointShadowProtocol in 
Figure 1 declares three pieces of after advice at ae39, ae43, 
and ae48; each is attached to the corresponding pointcut 
setting, settingX, or settingY. 


An AspectJ program can be divided into two parts: base 
code which includes classes, interfaces, and other standard 
Java constructs and aspect code which implements the cross- 
cutting concerns in the program. For example, Figure 1 
shows an AspectJ program that associates shadow points 
with every Point object. The program can be divided into 
the base code containing the classes Point and Shadow, and 
the aspect code which has the aspect PointShadowProtocol 
that stores a shadow object in every Point. Moreover, the 
AspectJ implementation ensures that the aspect and base 
code run together in a properly coordinated fashion. The 
key component is the aspect weaver, when ensures that ap- 
plicable advice runs at the appropriate join points. For more 
information about AspectJ, refer to [2]. 


To focus on the key ideas of our work, we do not discuss 
how to represent standard constructs such as classes and in- 
terfaces in this paper because they can be represented using 
existing techniques [13, 14]. To simplify the presentation we 
present only those join points related to method and con- 
structor calls. 


2.2 System Dependence Graphs for Object- 


Oriented Programs 
The system dependence graph (SDG) [13, 14] for an object- 
oriented program is a collection of method dependence graphs; 
each of which represents a main() method or a method in 
a class of the program. Additional arcs represent direct or 


indirect dependences between a call site and the invoked 
method and transitive interprocedural data dependences. A 
method dependence graph (MDG) for a method m is a di- 
rected graph’ whose vertices represent statements or predi- 
cate expressions in m; arcs represent control and data depen- 
dences. The MDG also has a unique vertex called method 
entry vertex to represent the entry into m. 


Formal parameter vertices are used to model parameter pass- 
ing between methods. There is a formal-in vertex for each 
formal parameter of the method and a formal-out vertex for 
each formal parameter that may be modified by the method. 
Each call site has an associated call verter and actual param- 
eter vertices: an actual-in vertex for each actual parameter 
and an actual-out verter for each actual parameter that may 
be modified by the called method. In addition, each formal 
parameter vertex is control dependent on the method entry 
vertex, and each actual parameter vertex is control depen- 
dent on the call vertex. 


The construction of the standard SDG can be performed 
by connecting MDGs at call sites. A call arc is used to 
connect the call vertex and the entry vertex of the called 
method’s MDG. Actual-in and formal-in vertices are con- 
nected by parameter-in arcs and formal-out and actual-out 
vertices are connected by parameter-out arcs. These param- 
eter arcs represent parameter passing. Moreover, to repre- 
sent the transitive flow of dependences in the SDG, summary 
arcs [7] are created by connecting an actual-in vertex to an 
actual-out vertex if the value associated with the actual-in 
vertex affects the value associated with the actual-out ver- 
tex. 


Existing SDGs for object-oriented programs can also rep- 
resent object-oriented features such as classes and objects, 
class extensions, interfaces and their extensions, polymor- 
phism, object parameters, and class libraries; details can be 
found in [11, 13, 14]. 


[Example] Figure 2 shows the SDG for the base code of the 
program in Figure 1, especially a part of class Point. In the 
figure, circles represent program statements and are labeled 
by statement numbers. Ellipses represent parameter ver- 
tices and are labeled with fi_in or fi_out for formal param- 
eters and aiin or ai_out for actual parameters. Following 
Larsen[13] we refer to a particular parameter vertex by pre- 
fixing the parameter label with the call or entry vertex upon 
which it is control dependent. For example, s17->a3_in 
refers to the parameter vertex representing the actual pa- 
rameter “_x_in=2” in the call to setX() at si17. In the 
figure, we use different types of arcs to represent control de- 
pendences, data dependences, method calls, and parameter 
bindings. For example, there are control dependences arcs 
(s17, a3_in) and (me9, f1_in) since a3_in is an actual-in 
vertex attached to a method call to setX() at s17 and f1_in 
is a formal-in vertex attached to the method entry vertex 
me9. p is defined in s16 and used in s17 and s18. Therefore, 
there are data dependence arcs (s16, s17) and (s16, s18). 
A parameter binding occurs at the call to setY() at s18 be- 
tween 2 in main() and _yin setY(). This parameter binding 
leads to a parameter-in arc (s18->a4_in, m11->f4_in) and 
a parameter-out arc (m11->f2_out, s18->a6_out). Finally, 


'A directed graph G = (V, A), where V is a set of vertices and A € 
V x V is a set of arcs. Each arc (v, v’) € A is directed from v to v’; 
we say that v is the source and v’ the target of the arc. 


there is a summary arc (s16->al_in, s16->a5_out) to repre- 
sent the fact that in Point () constructor, the value of 1 that 
is passed to Point() affects the value of x that is returned 
by Point(). 


3. SYSTEM DEPENDENCE GRAPHS FOR 
ASPECT-ORIENTED PROGRAMS 


We next present our system dependence graphs for aspect- 
oriented programs and our system dependence graph con- 
struction algorithm. We also discuss the representation of 
aspects, aspect and class interaction, and a complete aspect- 
oriented program using our representation. 


3.1 Advice, Introduction, Pointcuts and 
Methods 


In addition to methods, an aspect may contain other mod- 
ular units such as advice and introduction. Since advice 
and introduction can be regarded as method-like units, we 
can also represent each piece of advice or introduction by 
a method dependence graph (MDG) as described in Section 
2.2. To keep our terminology consistent in the rest of paper, 
we use the word “module” to stand for a piece of advice, a 
piece of introduction, or a method in an aspect and also a 
method in a class, and use a module dependence graph to 
represent it. 


A module dependence graph (MDG) for a module m, denoted 
by Gua, is a directed graph (e,V,A) where e is an entry 
vertex to represent the entry into m; V = V, UV. such that 
Vn is a set of normal vertices and V~ is a set of call vertices; 
A= AconUAaaz: such that Acon is a set of control dependence 
arcs such that any (u,v) € Acon iff u is control-dependent 
on v ; Agat is a set of data dependence arcs such that any 
(u,v) € Agat iff u is data-dependent on v . 


Gwuoa is similar to the procedure dependence graph defined 
in [7] for representing a procedure in a procedural program. 
A vertex is called a normal vertex if it represents a statement 
or predicate expression in m without containing a call or 
object creation. Otherwise it is called a call verter. Gupa 
consists of two types of arcs, i.e., control dependence arcs 
and data dependence arcs. Let u and v be two statements in 
m, informally u is directly control-dependent on v if whether 
u is executed or not is directly determined by the evaluation 
result of v, and wu is directly data-dependent on v if the value 
of a variable computed at v has a direct influence on the 
value of a variable computed at u. 


For a piece of before, after, or around advice a, we use an 
MDG to represent a; the MDG has a unique entry vertex to 
represent the entry into a. To represent a piece of introduc- 
tion, two cases should be considered. If a piece of introduc- 
tion i introduces a method (or constructor) into a class, we 
use the MDG to represent 7; the MDG has a unique entry 
vertex to represent the entry into 7. If a piece of introduc- 
tion i introduces a field f to a class, we need not construct 
the MDG for i. In such a case, we regarded f as an aspect 
instance variable (we discuss this issue in Section 3.2). For a 
pointcut pc, since it has no body code, we use a vertex called 
join-point vertex to represent pc; it also represents the entry 
into pce. 


3.2 Base and Extended Aspects 


We discuss how to use aspect dependence graphs to repre- 
sent a base or extended aspect”. 


Base Aspects. To facilitate the analysis of an individual 
aspect, we represent each aspect in an aspect-oriented pro- 
gram by an aspect dependence graph. 


Let a@ be an aspect with k modules {m;|t = 1, 2,...,&.} and 
G; = (e:,Vi,A;) be the MDG for module m;. An aspect 
dependence graph (ADG) for a, denoted by Gana, is a di- 
rected graph (e*, €%, V*, A®), where e® is the aspect entry 
verter; E* = Uke; is the set of entry vertices of the mod- 
ules in a. V* = UL, ViUVAUVZUVEUVS UVES, such that 
U,V; is the set of vertices; each represents a statement or 
control predicate in the modules in a; V,¢ is the set of join- 
point vertices, V7; or V7, is the set of formal-in or formal-out 
vertices; Vx* or V~ is the set of actual-in or actual-out ver- 
tices. AY = U*_, A;U A%,, U Aji U Ap U Ag cupAs U AS such 
that URL, Aj is the set of control dependence arcs and data 
dependence arcs in the MDGs of modules in a; A%,, is the 
set of membership arcs; AZ; or Aj, is the set of parameter-in 
or parameter-out arcs; A? is a set of call arcs; Aj is the set 
of pointing arcs; AZ is a set of summary arcs. 


Gapa is acollection of MDGs; each represents a piece of ad- 
vice, a piece of introduction, or a method in a. The aspect 
entry verter represents the entry into a. An aspect member- 
ship arc represents the membership relationships between a 
and its members (advice, introduction, pointcuts, or meth- 
ods) by connecting a’s entry vertex to the entry vertex of 
each member. A join-point vertex represents a pointcut in 
a. Formal-in and formal-out vertices represent formal pa- 
rameters in a module m; there is a formal-in vertex for each 
formal parameter of m and a formal-out vertex for each for- 
mal parameter that may be modified by m. Actual-in and 
actual-out vertices are used to represent actual parameters 
at each call site in a module m; there is an actual-in vertex 
for each actual parameter of m and an actual-out vertex for 
each actual parameter that may be modified by m. Each 
actual-in or actual-out vertex is control dependent on its 
corresponding call vertex and each formal-in or formal-out 
vertex is control dependent on the entry vertex. 


A call arc represents the calling relationship? between two 
modules m: and m2 in a by connecting the call vertex in 
mi to the entry vertex of m2’s MDG if there is a call in 
m1’s body to call m2. A parameter-in or parameter-out arc 
represents the parameter passing between modules m; and 
mz in a by connecting an actual-in and a formal-in vertex to 
form a parameter-in arc, and a formal-out to an actual-out 
vertex to form a parameter-out arc if there is a call in m1’s 
body to call m2. A summary arc models the transitive flow 
of dependence across a module call within a, as introduced 
in Section 2.2. 


Consider an aspect instance variable fin a. Since the vari- 
able is accessible to all modules in a, we create a formal-in 
or formal-out vertex for each module in @ that references f. 


Finally, for each pointcut pc in a, we connect the aspect 


?We can use an existing technique [13] to represent a base and ex- 
tended class. 


3Since advice in AspectJ is automatically woven into some method(s) 
by a compiler (called ajc) during aspect weaving process, there exists 
no call to the advice. As a result, there exists no call from introduc- 
tion (or method) to advice. 


£1_in: x=x_in 
£2_in: y=y_in 
£3 in: p=p_in 
£3 out: p_out=p 
£4 in: s=s_in 


£5 in: shadowCount= 

shadowCount_in 

£5 out: shadowCount_out 
=shadowCount 


£6_in: shadow=shadow_in 
£6 out: shadow out=shadow 
al_ 
al_out: p=p_out 
a2_in: s_in=s 


in: p_insp 


a3_in: shadow_in=shadow 
a3_out: shadow=shadow_out 
a4_in: x_in=x 
a5_in: y_insy 


a6_in: shadowCount_in=shadowCount 
a6_out: shadowCount=shadowCount_out 


’ ; control dependence arc 


‘ DP cgedecedstccsndied! > 
| data dependence arc 


; parameter-in, parameter-out, 
i pointing, or call arc 


: summary arc 


Figure 3: An ADG for aspect PointShadowProtocol in Figure 1. 


entry vertex to pc’s join-point vertex through an aspect 
membership arc, and also pc’s join-point vertex to the en- 
try vertex of its corresponding advice by a pointing arc to 
represent the relationship between them. Since there exists 
parameter passing between pc and its corresponding advice 
a, parameter-in and parameter-out arcs are created to con- 
nect an actual-in vertex to a formal-in vertex, and also a 
formal-out vertex to an actual-out vertex between pc and a. 


[Example] Figure 3 shows the aspect dependence graph for 
aspect PointShadow Protocol. The rectangle represents the 
aspect entry vertex and is labeled by the statement label as- 
sociated with the aspect entry. Circles represents statements 
and are labeled with the corresponding statement number 
in the aspect. For example, ase27 is an aspect entry ver- 
tex; ae39, ae43, and ae48 are advice entry vertices; me29, 
me32, and me34 are method entry vertices, p36, p37, and 
p38 are join-point vertices. (ase27, ae39), (ase27, me32), 
and (ase27, pe36) are aspect membership arcs. Each entry 
vertex is the root of a sub-graph which is itself a partial 
SDG. Each sub-graph may contain control and data depen- 
dences, call and parameter, pointing, and summary arcs. 
(p36,ae39), (p37,ae43), and (p38,ae48) are pointing arcs 
that represent interactions between pointcuts and their cor- 
responding advice. To represent parameter passing between 
pointcut p36 and its corresponding after-returning advice, 
formal-in and formal-out vertices are created for the for- 
mal parameters x, y, and p of the advice, and actual-in and 
actual-out vertices are created for the parameters x, y, and p 
of pointcut setting. Also parameter-in and parameter-out 
arcs are created to connect these formal and actual vertices. 


Extended Aspects. An aspect can extend an abstract as- 
pect‘, a class, and can implement any number of interfaces. 
The ADG should be able to represent an extended aspect. 
Given an abstract aspect a and an aspect a’ that extends 
a, we can construct the ADG for a’ as follows. We first con- 
struct the MDG for each module m in a’, and then reuse 
the MDGs of all modules that are inherited from a. There 
is an entry vertex for a to represent the entry into a, and 
aspect-membership arcs are used to connect the aspect entry 
vertex to the entry vertex of each modules in a. The aspect- 
membership arcs are also used to connect the aspect entry 
vertex to the entry vertices of any module in a that are in- 
herited by a’. We also use formal-in and formal-out vertices 
to model the parameter passing in a and instance variables 
in a and a’ that may be referenced by a call to this mod- 
ule. Similarly, formal-out vertices for a module represent the 
module’s formal parameters and instance variables in super 
or extended aspects that may be modified by a call to this 
module. Similarly, we can represent an aspect that extends 
a class or implements an interface using existing techniques 
originally developed for object-oriented programs [11, 13]. 


3.3 Interactions between Aspects and Classes 
An aspect can interact with a class in several ways: by ob- 
ject creation, method call, introduction declaration, and join 
point. An SDG should be able to represent these interactions 
between aspects and classes. 


Object Creation. A module m in an aspect a@ may create 
an object of a class C through a declaration or by using 


4In AspectJ, an aspect can not extend a concrete aspect. 


an operator such as new. At this time, there is an implicit 
call from m to C’s constructor. To represent this implicit 
constructor call, a call arc is added to connect the call vertex 
in @ at the site of object creation to the entry vertex e of the 
MDG of C’s constructor. Also, at the call vertex, actual- 
in and actual-out vertices are added to match the formal- 
in and formal-out vertices in the MDG of C’s constructor. 
For example, statement s40 in Figure 1 represents an object 
creation of class Shadow in aspect PointShadowProtocol. To 
represent this object creation, in the SDG of Figure 4, a call 
vertex is created for s40; it is connected to the entry vertex 
me22 of the Point’s constructor. Actual-in vertices (a7_in 
and a8_in) and actual-out vertices (ai0_out and a10_out) 
for s40 are also added to match the formal-in and formal-out 
vertices for Point’s constructor. 


Method Call. An aspect a may have a call from its module 
m, to a method mz in the public interface of class C. In 
this case, a call arc is added to connect the call vertex of 
my to the entry vertex of m2’s MDG, and parameter-in and 
parameter-out arcs are added to connect actual-in vertices 
to formal-in vertices, and formal-out vertices to actual-out 
vertices between m; and m2. For example, statement s45 in 
Figure 1 represents a call to method getX() of class Point 
in aspect PointShadowProtocol. To represent this method 
call, in the SDG of Figure 4, a call vertex is created for s45; 
it is connected to the entry vertex me5 of method setX(). 
An actual-in vertex (a7_in) for s45 is added to match the 
formal-in vertex for method setX. 


Introduction Declaration. An aspect a may declare a 
piece of introduction i that publicly introduces one method 
(or constructor) into a class C. To represent such an in- 
teraction, the entry vertex of C’s class dependence graph is 
connected to the entry vertex of i’s MDG by a class member- 
ship arc because i can potentially affect the type structure of 
C. If a piece of introduction in a@ publicly introduces a field 
finto a class C, we regard fas an instance variable of both 
a and C. Therefore, fis accessible to all modules in @ and 
C. In this case, we create a formal-in and formal-out vertex 
for f for each module in @ and C in which f is referenced. 
However, if a piece of introduction in @ privately introduces 
a field finto a class C, fis only accessible to all modules in a. 
In this case, we create a formal-in and formal-out vertex for 
f only for each module in a. For example, statement s31 in 
Figure 1 represents a piece of introduction that privately in- 
troduce a field shadow into class Point; this means only code 
defined in PointShadowProtocol can access shadow. To rep- 
resent this introduced field, in the SDG of Figure 4, only a 
formal-in vertex (f9_in) for shadow is created for method 
getShadow() that references shadow, and both a formal-in 
vertex (f9_in) and a formal-out vertex (£9_out) for shadow 
are created for method associate() that modifies shadow. 


Join Point. An aspect may be woven into one or more 
classes at some join points, declared within pointcuts which 
are used in the definition of advice. By carefully examining 
the pointcuts and their associated advice, one can deter- 
mine those methods that a piece of advice may advise. This 
information can be used to connect the base program and 
aspects. Just as an aspect weaves itself into the base pro- 
gram at some join points, we weave the MDGs for advice 
into the partial SDG at join-point vertices (Section 3.5 will 
discuss this issue in detail). For example, the after advice 


declared in aspect PointShadowProtocol (lines ae43-s47) of 
Figure 1 may weave into method setX() of class Point. To 
represent this weaving issue, in the SDG of Figure 4, a weav- 
ing arc (me9, p37) is created to connect the entry vertex me9 
for method setX() to the join-point vertex p37 for pointcut 
settingX. 


3.4 Complete Aspect-Oriented Programs 
We next present a system dependence graph for a complete 
aspect-oriented program. 


Let P be an aspect-oriented program with n modules {m,|i = 
1,2,...,n.} and G; = (e:,Vi, Ai) be the MDG for mod- 
ule m;. An system dependence graph (SDG) for P, de- 
noted by Gspa, is a directed graph (€?, V”,A”), where 
EP = ULye; is the set of entry vertices of the modules in 
P. VP = ULV; UVE UVP UVP, U V2 UVZ, such that 
U*_,V; is the set of vertices; each represents a statement or 
control predicate in the modules in P; V,z is the set of join- 
point vertices; V;, or V7, is the set of formal-in or formal-out 
vertices; V?. or VX, is the set of actual-in or actual-out ver- 
tices. AP = Uj, A; U AP, U AR, U AP U ADU AZ, U AP such 
that URL, Aj is the set of control and data dependence arcs 
in the MDGs of modules in P?; A?, or Af, is the set of 
parameter-in or parameter-out arcs; A® is a set of call arcs; 
AZ is the set of pointing arcs; A%, is the set of weaving arcs; 
A® is a set of summary arcs. 


Gspq@ is a collection of MDGs; each represents a main() 
method, a method of a class, a piece of advice or introduc- 
tion, or a method of an aspect. Gspq also contains some 
additional arcs to represent direct or indirect dependences 
between a call and the called module and transitive inter- 
procedural data dependences. 


Gspq@ uses join-point vertices to represent pointcuts in P. 
Gspa@ also uses formal-in and formal-out vertices to rep- 
resent formal parameters in a module, and actual-in and 
actual-out vertices to represent actual parameters at each 
call site. In Gspq, call arcs represent the calling and callee 
relationships between modules. Weaving arcs connect the 
MDG for a method to the MDG for its corresponding ad- 
vice; these arcs represent the relationships between advice 
and those methods that the advice may affect. Actual-in 
and formal-in vertices are connected by parameter-in arcs 
and formal-out and actual-out vertices are connected by 
parameter-out arcs to model the parameter passing between 
modules. Gspg uses summary arcs to represent the transi- 
tive flow of dependences. 


[Example] Figure 4 shows the complete SDG for program 
in Figure 1, which was constructed by the algorithm de- 
scribed in Figure 5. 


3.5 The Algorithm for SDG Construction 


Our SDG construction algorithm for an aspect-oriented pro- 
gram P consists of four steps: (1) preprocessing each aspect 
and class; (2) building MDGs for modules; (3) connecting 
MDGs at callsites; (4) weaving MDGs at join points. 


Figure 5 shows our SDG construction algorithm BuildSDG. 
As input BuildSDG gets the control flow graph for each mod- 
ules in all aspects and classes of P, and as output BuildSDG 
returns the P’s SDG. First, BuildSDG preprocesses each as- 
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Figure 4: An SDG of the program in Figure 1. 


pect and class in P to get those kinds of information that 
are necessary for constructing the SDG (lines 1-12). Sec- 
ond, BuildSDG builds the MDG for each piece of advice, 
introduction, and method in an aspect or class. It builds 
these MDGs in a bottom-up fashion according to the aspect 
and class hierarchies (lines 13-31). After that, BuildSDG 
calls Connect () to connect these MDGs at call sites to form 
a partial SDG for P (line 32). Finally, BuildSDG builds 
the complete SDG for P by (1) calling Weaving() to weave 
the MDG for each piece of advice into the MDGs for its 
corresponding methods in the partial SDG, and (2) calling 
AddSummaryArcs() to compute summary arcs at call sites 
regarding both aspects and classes (lines 33-34); we can use 
an existing technique presented in [18] to implement the pro- 
cedure AddSummaryArcs(). In the following, we describe our 
algorithm step by step. 


Step1: Preprocessing Aspects and Classes. In this 
step, BuildSDG first identifies advice, introduction, and meth- 
ods that require new MDGs, and then computes the GREF 
and GMOD sets for each module. Finally, BuildSDG deter- 


mines the affected-method set for each pointcut. 


(1) Identifying Advice, Introduction, and Methods Requir- 
ing New MDGs. BuildSDG uses an existing algorithm [14] 
to identify methods in each class that require a new MDG. 
It builds on this idea to identify advice, introduction, and 
methods in each aspect that requires a new MDG. We de- 
scribe this identification process only for aspects here; for 
classes, one can refer to [14]. 


For an aspect a, BuildSDG calls a marking procedure to op- 
erate on a’s call graph to identify the advice, introduction, 
and methods that require new MDGs. First, it marks the 
advice, introduction, and methods declared in a. Second, if 
a extends some base aspects’, it marks the advice, introduc- 
tion, and methods in the base aspects that can reach these 
marked advice, introduction, and methods by performing a 
backward traversal on a’s call graph from these marked ad- 
vice, introduction, and methods. Finally, all marked advice, 


°We can use a similar technique to handle the case that a is extended 
from a class or interface. 


algorithm BuildSDG 


input Control flow graphs (CFGs) of program P 
output System dependence graph (SDG) of P 
declare 


begin BuildSDG 
/* Step 1: Preprocessing the program P */ 
1] foreach class C 
2 Identify the methods that need new MDGs 
3] endfor 
4] foreach aspect A 
5 Identify the advice, introduction, and methods that 
need new MDGs 
6] endfor 
7| foreach module m 
8 Compute GREF and GMOD sets for m 
9] endfor 
10] foreach pointcut pe 
11 Compute affected-method set for pe 
12] endfor 
/* Step 2: Build MDGs for methods in each class and 
advice, introduction, and methods in each aspect */ 
13] foreach class C 
14 Construct an MDGs for each method in C 
15] endfor 
16] foreach aspect A 
17 foreach advice, introduction, or method m declared in A 


18 Compute control dependences for m 
19 Compute data dependences for m 

20 Expend objects in m 

21 Compute data dependences for objects 
22 endfor 


23 foreach advice, introduction, or method m 
in the base aspects 


24 if m is “marked” then 

25 Copy old module dependence graph 

26 Adjust callsites 

27 else 

28 Reuse m’s old module dependence graph 
29 endif 

30 endfor 

31] endfor 


/* Step 3: Connecting MDGs at call sites */ 
32] Connect () 

/* Step 4: Weaving MDGs at pointcut sites */ 
33] Weaving () 

34] AddSummaryArcs() 

end BuildSDG 


Figure 5: Algorithm for SDG construction. 


introduction, and methods require new MDGs. 


(2) Determine GREF and GMOD Sets for Each Module. 
BuildSDG uses a’s call graph to compute the interface (i.e., 
two sets GREF and GMOD), for the advice, introduction, 
and methods that require new MDGs. For a piece of ad- 
vice, introduction, or method m, GREF(m) is the set of 
non-local variables (i.e., parameters, instance variable, or 
data members) to which m refers, and GMOD(m) is the set 
of non-local variables that m might modify. Using a tech- 
nique that is similar to the construction of a callsite or entry 
site for a method, which is described in Section 2.2, (1) a 
complete call site (i.e., call and actual parameter vertices) 
for a method call statement can be created, and (2) a com- 
plete entry site (i.e., entry and formal parameter vertices) 
for a piece of advice, introduction, or method m can be cre- 
ated based on the GREF and GMOD sets of m. GREF(m) 
and GMOD(m) can be determined by an existing data-flow 
analysis algorithm [12]. 


(3) Determine Affected-Method Sets for Each Pointcut. In 
this phase, BuildSDG calls PointcutAnalysis() to perform 


static analysis on each pointcut to determine the methods 
that the pointcut may affect. As input PointcutAnalysis() 
gets a pointcut pc, and as output PointcutAnalysis() re- 
turns a set called affected-methods-set which records meth- 
ods that may be affected by pc. 


Step 2: Building MDGs for Modules. In this step, 
BuildSDG uses an existing algorithm [14] to construct an 
MDG for each method in each class and uses a slightly mod- 
ified version of the algorithm to construct an MDG for each 
piece of advice, introduction, and method in each aspect. 
We briefly describe the algorithm here; details can be found 
in [14]. 


BuildSDG constructs the module dependence graph for a 
piece of advice, introduction, or method m declared in a new 
aspect based on m’s control flow graph. BuildSDG builds 
the control dependence graph for m using an existing algo- 
rithm [6], and builds the data dependence graph for m in 
three phases. First, BuildSDG preprocesses m using an al- 
gorithm that is a modified version of the usual data depen- 
dence graph construction algorithm [1]. Second, BuildSDG 
expands a vertex that references an object into the repre- 
sentations. Third, BuildSDG computes data dependences for 
data members of the objects. These three steps can handle 
objects at call sites, objects as parameters, and polymor- 
phic objects. In addition, BuildSDG constructs the mod- 
ule dependence graph for a piece of advice, introduction, or 
method m declared in a base aspect using a similar way as 
described in [14]. 


Step 3: Connecting MDGs at Call Sites. In this step, 
BuildSDG connects the MDGs created in Step 2 at call sites 
to form a partial SDG for an aspect-oriented program. At 
each call site, BuildSDG connects the MDG for the called 
introduction or method to the MDG for the calling advice, 
introduction, or method using three types of arcs: (1) a call 
arc connects a call vertex to the entry vertex of a called in- 
troduction or method; (2) a parameter-in arc connects each 
actual-in vertex at the call site to the corresponding formal- 
in vertex; (3) a parameter-out arc connects each formal-out 
vertex to the corresponding actual-out vertex at the call site. 


At each pointcut site, BuildSDG connects the join-point ver- 
tex for a pointcut to the entry vertex of its corresponding 
advice using three types of arcs: (1) a pointing arc connects 
a join-point vertex to the entry vertex of its corresponding 
advice; (2) a parameter-in arc connects each actual-in vertex 
at the pointcut site to the corresponding formal-in vertex at 
advice site; (3) a parameter-out arc connects each formal- 
out vertex at the advice site to the corresponding actual- 
out vertex at pointcut site. Moreover, if multiple pieces of 
advice apply to the same pointcut, BuildSDG connects the 
join-point vertex of the pointcut to the entry vertex of each 
piece of advice by pointing arcs respectively. In this case, 
we ignore the advice precedence because the connection is 
not related to the resolution order of the advice. 


Step 4: Weaving MDGs at Join Points. To form the 
complete SDG, we need to know some join points in the 
MDGs for methods at which the MDGs for methods and 
their corresponding advice can be woven in a natural way. 
As we discussed previously, since an aspect-oriented pro- 
gram is woven at some join points specified in pointcuts, we 
can use join-point vertices for weaving MDGs for advice and 


Table 1: Parameters contributing to the SDG size. 
Largest number of statements in a single advice, 
Largest number of arcs in a single advice, 
Largest number of formal parameters for any 


; Largest number of instance variables in an 
r Largest number of call sites in any advice, 
Depth of inheritance tree determining number 


Number of advice, introduction, and methods 


methods. The task for weaving the complete SDG consists 
of two phases: (1) weave the MDGs for advice in aspects 
into the MDGs for their corresponding methods in classes; 
(2) add summary arcs to form the final complete SDG. 


Weaving() connects the entry vertex of each method’s MDG 
in the partial SDG to the join-point vertex of a pointcut that 
refers to the method by a weaving arc. If the advice attached 
to the pointcut is a piece of around advice that contains 
a proceed() clause, Weaving() connects the proceed call 
vertex to the entry vertex of the original method’s MDG by a 
call arc to represent that the around advice may execute the 
proceed() call, which leads to execute the original method 
under the join point declared by the pointcut. 


To model parameter passing between the method and its 
corresponding advice, Weaving() uses a similar technique 
as in phase (1). For each join-point vertex, actual-in and 
actual-out vertices are created for each parameter of the 
pointcut. For each entry vertex of the advice’s MDG, formal- 
in and formal-out vertices are created for each formal pa- 
rameter in advice. Weaving() uses parameter-in arcs to 
connect the actual-in vertices to the formal-in vertices, and 
uses parameter-out arcs to connect formal-out vertices to 
the actual-out vertices between the pointcut and the advice. 
Weaving() does this iteratively until all pieces of advice in 
all aspects have been processed. 


3.6 The Size of SDG 


The size of SDG is critical for applying it to the practi- 
cal development environment for aspect-oriented programs. 
Here we try to predict the size of SDG based on the work of 
Larsen and Harrold [13], who gave an estimate for the size 
of the SDG for object-oriented programs. 


In AspectJ, class declarations are like class declarations in 
Java except that they can also include pointcut declarations, 
and aspect declarations are like class declarations in Java 
except that they can also include pointcut, advice, and in- 
troduction declarations. As a result, we can apply Larsen 
and Harrold’s approximation here to estimate the size of the 
SDG of an aspect-oriented program by regarding an aspect 
as a class-like unit and a piece of advice or introduction as a 
method-like unit. However, since our SDG is constructed for 
an aspect-oriented program, its size may be different than 
the SDG of an object-oriented program. 


Table 1 lists the parameters that contribute to the size of 
an SDG, denoted by Gspa, for aspect-oriented programs. 
We give a bound on the number of parameters for any ad- 


vice, introduction, or method m, denoted by Yparam(m), 
and use this bound to compute an upper bound on the size 
of a single advice, introduction, or method m, denoted by 
Tsize(m). Based on Ysize(m) and Ymodule (number of ad- 
vice, introduction, and methods in an aspect-oriented pro- 
gram), we can compute the upper bound on the number of 
vertices in Gspq including all aspects and classes, denoted 
by Ysize(Gspq) that contribute to the size of the SDG of 
the program. 


YT Param (m) = Yparam + Yinstant3 

Tsize(m) = O(Werter tYeallsite* (1+ tree #(2*T Param (m)))+ 
2* YParam(m)); 

Tsize(Gspa) = O(Tsize(m) * Ymodule): 


From the above estimate, we can see that Tsize(Gs pq) pro- 
vides only a rough upper bound on the number of vertices 
in an SDG. In practice an SDG may be considerably more 
space efficient. 


4. RELATED WORK 


We discuss related work in the area of developing depen- 
dence based representations (DBRs), a general class of pro- 
gram representations that includes SDGs. 


DBRs have been primarily studied for procedural programs 
to support compiler optimization and develop software engi- 
neering tools. Ferrante et al. [6] use the program dependence 
graph (PDG) to explicitly represent control and data depen- 
dences in a procedural program. The envisioned uses are 
compiler optimizations and program slicing [20]. Horwitz 
et al. [7] extend the PDG to the system dependence graph 
(Horwitz-Reps-Binkley SDG for short) to represent a proce- 
dural program with multiple procedures. Cheng [5] presents 
a process dependence net which is the generalization of the 
PDG to represent program dependences in a concurrent pro- 
cedural program. The goal is to support the development of 
concurrent programs. Krinke [10] uses a threaded program 
dependence graph that can present interference dependences 
in a concurrent program; the intended application is pro- 
gram slicing. Although these DBRs can effectively represent 
the features in procedural programs, they were not designed 
to represent object-oriented and aspect-oriented constructs. 


DBRs have been applied to represent object-oriented pro- 
grams recently. Larsen and Harrold [13] present a new 
system dependence graph (Larsen-Harrold SDG), that ex- 
tends the Horwitz-Reps-Binkley SDG, to represent object- 
oriented programs for program slicing. Their SDG can rep- 
resent many object-oriented features such as classes and 
objects, inheritance, polymorphism, and dynamic binding. 
Liang and Harrold [14] further extend the Larsen-Harrold 
SDG to represent object parameters, polymorphic objects, 
and class libraries. Kovacs et al. [11] extends the Larsen- 
Harrold SDG to represent Java programs. In addition to 
general object-oriented features, their SDG can represent 
some Java-specific features such as static variables, inter- 
faces, and multiple packages. On the other hand, McGre- 
gor et al. [15] take a different way to develop a DBR called 
object-oriented program dependency graph (OPDG) for object- 
oriented programs. The OPDG is an extension of the PDG 
[6] and can be used as a basis for computing layered static 
slices for object-oriented programs. Chen et al. [4] also 
extends the PDG [6] to a object-oriented dependency graph 


for representing object-oriented programs. These DBRs can 
effectively represent object-oriented programs, but are not 
designed to represent specific aspect-oriented features such 
as join points, advice, introduction, aspects, aspects, and 
aspect inheritance in aspect-oriented programs. 


Recently, Zhao [21] presents a DBR called an aspect-oriented 
system dependence graph (ASDG) for slicing aspect-oriented 
programs. The ASDG consists of an SDG for the non-aspect 
code, a group of dependence graphs for the aspect code, and 
some additional vertices and arcs to represent dependences 
between aspects and classes. However, Zhao dose not give 
a concrete algorithm for constructing the ASDG, therefore 
how to represent aspect weaving in an SDG is not clear. We 
see our work differing from Zhao’s in several ways. First, 
we give a concrete algorithm for constructing an SDG for 
aspect-oriented programs. Our algorithm gives an efficient 
way to weave dependence graphs for base and aspect code 
and to model the parameter passing between pointcuts and 
their corresponding advice. Second, in contrast to Zhao’s 
approach (which requires the creation of some extra weav- 
ing vertices to facility the weaving of dependence graphs 
for base and aspect code), we use pointcuts as join points 
directly, then use pointing and weaving arcs to represent 
aspect weaving. This approach reflects the actions of an 
aspect weaver, which weaves the aspect code into the base 
code at join points. Third, our SDG can represent many 
more aspect-oriented constructs. These constructs include 
around advice, advice precedence, introduction scope, and 
aspect inheritance. 


5. CONCLUDING REMARKS 


In this paper we extend previous system dependence graphs 
(SDGs) to represent aspect-oriented programs and present 
an algorithm for constructing SDGs. Our SDG construc- 
tion algorithm consists of several steps. It first constructs 
a module dependence graph (MDG) for each piece of ad- 
vice, introduction, and method in each aspect and class. It 
then uses existing techniques for object-oriented programs 
to connect these MDGs at call sites to form a partial SDG. 
Finally, our algorithm weaves the MDG for each piece of ad- 
vice into the partial SDG for those methods whose behavior 
may be affected by the advice. The result is the complete 
SDG. Our SDGs capture the additional structure present in 
many aspect-oriented features such as join points, advice, 
introduction, aspects, and aspect inheritance, and various 
types of interactions between aspects and classes. They also 
correctly reflect the semantics of aspect-oriented concepts 
such as advice precedence, introduction scope, and aspect 
weaving. SDGs therefore provide a solid foundation for the 
further analysis of aspect-oriented programs. 
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